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ABSTRACT 


This thesis presents the development of a database 
System for Republic of Korea Army's personnel management. 
Database processing has grown significantly in computer 
science areas and also in management of certain organiza- 
tionsil Database system designers establish objectives of 
database system organizations before initiating development. 
An important consideration in database development is to 
assure that it can be used for a wide variety of application 
and can be changed quickly and easily. ROK Army needs an 
end-user application system because users usually require 
Statistical information periodically. Software engineering 
goals are discussed to develop an efficient end-user 
application system. To address software engineering goals, 
top-down design and structured programming technique are 


used as tools. 





rel. 


TABLE OF CONTENTS 


IDINURICNDI CS IUIIGIN = SS 3S aa laa int 
BUMOCGIRGTUINDD) = = SS OO aaa all 16 
Ae ee eee tte eee a 16 
Bonet Oh Se mer be oONINEGe MANAGEMENT ------------- a 
1. Basic Concept of Personnel Management ----- 17 
a onsommneme > HOGCUReEMeNt 2=> >= ==------------=- 1 
So crcommemeralcat1on and Training ---------- 18 
ee cocomimere ASceselmemt --=-=—--=----=<---------- 18 
SWE SOMmel, “Wish ee cee ees a Ne eal 19 
Oyo) EEE SODAS Jags NE OURO 10119 aN 19 
5 NSP SMa I ESD 1c Be TO 20) 
C. MAJOR REQUIRED INFORMATION IN PERSONNEL 
MANAGEMENT TO INCREASE WAR POWER -------------- al 
D. ADVANTAGES AND DISADVANTAGES OF A DATABASE 
Syeosee ee Ene Pgh 1 > eee = = = = = Se aS 
Eee OO OO i a a 24 
See eee EV One Pal ABASE  StolEM -=-=--------- 26 
A. INTRODUCTION ---------------------------------- 26 
Pee Genome xomiC TERMINON@GY —--------------- 26 
Meebomrcaimames Physical Data Description ----- 26 
2. Data ----------- 2 - een rrr nee rere reer eee OM 
3. Field (Data Item, Data Element) ----------- oe 
4. Group of Fields (Segment, Data Aggregate)-- 28 


RAC ec SSSR ee 2 ee ee 28 





ry 


@,  DeuzslbeS@ =-6 25565656555 SS See eee eee 28 


eee da Mines CS eRe 2 Oe ee 28 

8. Database Management System (DBMS) ------- 28 

5 DBUEIDBSE SSS OTN ada ae 1s, 
Ce RC Een Oh EmOreOAnNGAos SYSTEM ----------- 29 
D. TYPICAL USER CLASSIFICATION OF DATABASE 

OOS TERNS SS SS a a a aaa 50 
PeteeObIJECTEVES OF DATABASE SYSTEM 

CORE Ze TE GTN SS a ial 5 
eb ew Evie OL MENT la =~ =~ === == 5 - === - = == 36 
Aree ENTRODUCT LOND == === ---5----------------------- 36 
B. DATABASE MODELS AND A DATABASE MODEL 

SIRS BO GIN = SS 4 
foo RKee hun Or eC ORELATIONAL DATABASE MODEL ---=- 59 
Dae eon DEPENDENCY AND DECOMPOSITION ----- 42 
Ig SICISL EN TBT ETS TG In al 45 

Pec Mar CmMeimES eiatngs 1S se = Sa Sa Se = 45 

neo wueOn OL ReGgurred Data =-------=---- 47 

Seemermeatysis and Design of Normal Forms ----- 48 

4. Analysis and Design of Relationships 

me heel Ise Ley SS RE 50 

PeeeOuotwntNT>s ANALYSIS AND ASSIGNMENT --------- oy 
G. DATABASE TESTING ---------------~------------ SZ 
fe CONCLUSION ---------------------------------- 55 
PvP ewoenenre bi CATION SYSTEM DEVELOPMENT --------- oie 
em eO® DUG PEON = 4 = <= 3 w= an = ew eee eo; 55 
Deere ths OF AN ABSTRACT ALGEBRAIC QUERY 


LAN GUILAGIR 33S ee ate 





GIVI AA TDC EGET TO) ANNES OB AG) SS 59 

ee ene eee ee = = a Sy 

roe RAO memnOCrooNGuaNiuy SIS ----~-----=-=-- 60 

I BSS TEN DIRS ILGIN| SS aa al 61 

Pec cima eceeoNIGONGeDE === -=-->--+------- 61 

aon aaa es ton == = ~~ =~ ee m= = = 2 = 62 

See tenes PO = —- => = — = - —------------+--- - SS 

Go BeOS ATIEMSE IVES ICN 65 
TONG GUS | ONi@Ree = = mm = ~~ we wn nw aw - 67 

wel. COCs one e COMMEND ATLONS ------------------ 69 
Pee ea vee BUS INE Soe MODEL ==—===-—----~--------------- 72 
omen oe A oOAMPLE EIST OF INTEGRATED ENTITY TYPES -- 78 
aoe Niece LISRWO THIRD NORMAL FORMS -------------- ca 
Peo iveee: A oAMPEE LIST OF RELATIONSHIPS ------------ 85 
See ve ee erro hMP bE Ar DICTIONARY ------------------ 86 


APPENDIX F: A SAMPLE LIST OF TRANSACTION PROCESSING 


ANALYSIS 2522 See es ee 90 
LIST OF REFERENCES ------------------------------------- 92 
SeeEE MENNGMRIBUTION LIST ©22-22---2--25------2--45---5--- 94 





PioleOrertGURES 


Hardware/Software Cost Trends --------------------- 11 
SOW hel ihemisyG Gm ——-—-——-----------~~--25--- 2% 13 
Terms Which Describe the Application Programmer's 

ee Cems cee eels ee ee me = ~~ oi 
neoeandard Database System ------------------------ 29 
Standard View-Points of a Database System --------- 30 
An Example of DBA's Organizational Relationships -- 3l 
An Example of a Relation -------------------------- 40 
Tie icmOn  aencicgtutOnal Schema ~----------->---- 41 
ETE Ge” Mavic Wires Jolt oS aR SE cal 58 
A Baseline for an Application System -------------- 64 





ACKNOWLEDGEMENT 


My country, Republic of Korea, invests a great deal of 
money for my graduate study. I will love my country end- 
Mescly. it am very grateful to numerous people for their 
help and encouragement. 

Most of all, I would like to express my appreciation 
to my thesis advisor, Professor Samuel H. Parry, for his 
enthusiastic guidance and support. Without the many hours 
of counseling and endless supply of ideas he provided, 
this thesis could not have been completed. 

I am also appreciative of the helpful comments for 
System analysis and development methodology given by 
second reader, Professor Richard S. Elster, Professor 
Roger W. Baylon, Charles R. Arnold, and Norman R. Lyons. 

A special thanks and mention is due to General Su-yong 
ie colonel Yong-ju Lee, Colonel Jong-sup Im, Colonel 
In-sang Woo, and Major Ho-jin Kim. They supported the 
Selection of data about the ROK Army's personnel 
management. Another special thanks is given to Lieutenant 
Selonel Smeeks who works in the U.S. Army Military Personnel 
Center in Alexandria, Virginia, Lieutenant Colonel Mikkeism 
who works in the U.S. Army Finance and Accounting Center 
in Indianapolis Indiana, Captain Philip H. Knorr who works 


at the Defense Manpower Data Center in Monterey, California, 





and Captain Smith who works at the Miltiary Personnel 
Office in the 7th Infantry Division. They provided the 
problems of database processing in their environment 
and were very helpful for the thesis approach. 

I also thank Ginger D. Kelley who is a secretary in 
the Department of Weapons Engineering. She spent much 
time typing this thesis. 

Finally, I want to express my sincere thanks to my 
family, my parents, wife Bok-im Bae, and daughter Hi-jin, 
for their understanding and encouragement, and for the 
sacrifices they have made during my graduate study. My 
daughter always said to me, '"!Please, don't go to school 
and play with me" in the evening and on the holidays. 


Now I can accept her earnest request. 


10 





I. INTRODUCTION 


It is obvious that it is the database system era in 
computer technology and applications. Database processing 
has grown significantly in computer science areas and also 
in management of certain organizations. The cost of 
computer hardware is decreasing rapidly. As capacity 
Mereases, the cost per bit of storage decreases. The 
software cost, however, which includes development and 
Maintenance cost, is growing rapidly. Figure 1.1 shows 


this relation [Ref. 1]. 
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On the other hand, personnel costs are increasing 
mapidiy. All of the Managers in any organization want to 
decrease the cost of production to get greater benefit. 
These situations motivate database system designers to 
Moneinue thearm=efforts to obtain more useful database 
myoeems. 

a important consideration in database development is 
to store data in such a way that it can be used for a wide 
Variety of applications and can be changed quickly and 
easily. To achieve the flexibility of data usage, three 
aspects ot database design and implementation are important. 
First, the data should be independent of each other (data 
independency) and functionally dependent on the key value. 
second, it should be possible to interrogate for user's 
requirements using application programs or the DBMS itself. 
Third, these data items should provide useful information 
for decision makers to analyze, to investigate, to plan 
and to manage in a certain organization. 

heets very dicficult to develop decease which perform 
in an optimal fashion. There are many different ways in 
which data can be structured and each has its own 
advantages and disadvantages. Different users want to 
use different data/information. It is hardly possible 
Memoatisty all of the users with one type of data organiza- 
ESOT . The normal form concepts of relational database 


models will be applied to develop databases for Korean 
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Army's Personnel Management, because the relational data 
model supports data independency better than other models 
and is easy to implement. 

To apply these databases for personnel management, a 
commercially available database management system (DBMS) and 
an end-user application system are needed. Some programming 
techniques will be discussed to develop an efficient end- 
user application system for any DBMS which uses a relational 
database model. The basic considerations for an end-user 
application system development are software engineering 
goals such as modifiability, efficiency, reliability, and 
understanability [Ref. 17]. 

As a result of this thesis, a standard database system 
for Republic of Korea Army's personnel management (officer 
personnel only) is developed based on software life cycle 
[Ref. 2] which is shown in Figure 1.2 and other similar 
publications [Ref. 15, 16, and 17]. Chapter II addresses 
the background, which relates to the database system 
development for Korean Army's personnel management, in 
terms of system requirements. Chapter III addresses the 
general overview of a database system to analyze software 
requirements. Chapter IV develops databases for Korean 
Army personnel management which can include all data that 
is required in Chapter II. Chapter V develops an end-user 
application system to extract some useful information for 


personnel management from databses developed in previous 
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Siapters.. Finally, Chapter V1 presents conclusions and 
recommendations based on the research presented in the 


thesis. 
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II. BACKGROUND 


A. INTRODUCTION 

The Republic of Korea (ROK) Army uses the general staff 
system of the USA field armies, corps and divisions, namely, 
foe persommel], G=Z, ianteiligence; G-3, operations and 
medinaneg; anaeG-4, logistics. The Army Headquarters has 
the responsibility for organizing, training and equipping 
the ROK ground forces for the conduct of sustained combat 
operations. To accomplish these ground operations, the 
ROK Army has many service branches. The ROK Army is the 
largest organization among military units and also in the 
ROK. For national security, the ROK Army is very important 
because it stands face-to-face with communist North Korea 
eme cone 155 mile DMZ. 

The ROK government spends a rather large percent of 
the total government budget for national defense, and the 
Department of National Defense spends a significant portion 
of the national defense expenditures for personnel. This 
is the largest investment in the ROK Army, but ROK's war 
power is less than communist North Korea. 

Pimouce tayoureduGe the mational defense expenditure 
and increase the war power, the Army needs a computerized 
management information system for personnel management. 


Therefore, some important functions of the Army's 
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departments of personnel management and some required 
information are analyzed as system requirements, and file 
systems and a database system are compared for a computerized 


system selection in this chapter. 


B. FUNCTIONS OF PERSONNEL MANAGEMENT 
Peedoee COncepe Of Personne! Management 

Personnel managers need data about the individual 
Hersonnel power and group personnel power to analyze, to 
investigate, to plan, and to apply it for their organizations. 
Information about individual personne] power can be derived 
from functions involving procurement, education and 
training, assignment, treatment, promotion and separation 
(retirement). Information about group personnel power 
can be derived by a collection of individual personnel power. 
It 1s important to increase individual and group personnel 
power in the personnel management field so that the right 
people move into the right jobs at the right times and 
under the right circumstances [Ref. 5]. Individual personnel 
Mewer becomes the basis for group personnel power. Each 
factor of individual personnel management will be discussed 
based on Ref. 3 and Ref. 4. 

2. Personnel Procurement 

PeLoOmelsNEOGIGomMent 15 a process of gaining the 

personnel for filling vacant positions which can not be 


mebied from within the organization itself. Efficient 
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personnel procurement requires some information concerning 
the candidate's education, qualification, experience, 
skills, degree, health, etc. ‘After candidates have been 
selected, their information can be kept and maintained so 
that it can be used at any time for transfer, new assignment, 
mMmeomotion, etc. The various new officers procurement 
Organizations are described in Reference 3. These sources 
and all personnel officers who are currently working in 
the Army are investigated for future plans and applications. 

> Personnel Education and Training 

Information about education and training of 

personnel is important and is used for personnel development 
ana promotion. This information is used to match cr minimize 
the difference between skills possessed by those who will 
occupy the position. A person's educational background 
Can be used to gain special knowledge required for placing 
a person in a particular job and to prepare that person 
for a new assignment. The basic education and training 
Organizations which perform the education and training 
to cadets and candidates are described in Ref. 4. All 
Army officers must follow a specified list of education 
and training courses for their development, promotion and 
assignment. 

i Personnel Assignment 

Personnel assignment deals with selecting the right 

officer personnel for the right positions. Three aspects 


must be considered for this job. 


dite 





ime EVeTy Vacant position must be filled by a person 
with the ability to carry out the job in the best manner. 

2. The capabilities and skills of each person must be 
meeted to the job so that he satisfies the job area. 

S. Each person who is selected for a new position 
must have finished compulsory education and training courses 
and must have carried out compulsory positions in each 
rank. 

weeerersonne.: lreatment - 

Personnel treatment deals with the physical and 
Beyenological aspects of the person and the job. These 
include such areas as mental and physical health, 
Meecredcion, rewards, personnel service, transportation, 
Salary, retirement plans, military insurance, annual 
pension and vacation (periodic, sick, reward, asking, etc.), 
eee. Mental and physical health conditions and rewards 
mrrect promotion and new assignments. Salary, military 
surance, annual pension and personnel service, etc. 
affect the life of the family. Recreation, awards, 
Bersonnel service, transportation, retirement plans and 
Vacations are very important for military morale [Ref. 6]. 

6. Personnel Promotion 

The promotion policy is that personnel, who have 

finished minimum service duration in a rank and posses the 


capability to perform in the upper level position, be 
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Mmvestigated by a promotion selection committee. Therefore, 
this information should be prepared and provided to the 
decision makers, namely the promotion selection committee. 
im this information, the list of personnel who can be 
promoted should be provided according to each rank and 
each brand of service. The promotion point tables of all 
personnel should be provided by incorporating several items 
into these tables. These items are the career which is 
required in the current rank, the result of fitness reports 
which are prepared annually on current rank, military 
education, rewards and punishments, class of physical 
and mental health condition, and the order of promotion 
recommended by commanders. The promotion selection committee 
will select the officers to be promoted each year from 
officers who are recommended for promotion according to 
above information, and the necessary number of officers 
determined by the number of vacant positions. The 
officers to be promoted the following year are decided 
upon at the end of each year. 

eee rSOmne biocparat10n 

Personnel separation occurs when personnei 

voluntarily ask to be retired from the Army through 
the process of retirement, or when some one can not continue 
in the Army because of problems with their mental or 


physical health condition. Personnel who request retirement 





must have worked for the minimum public service duration in 
the Army. The minimum public service durations are different 
between resource organizations. If personnel have studied 

in commissioned organizations, they must have worked 

double period for a commissioned duration. However, if 
personnel reach the age limitation, rank limitation or 
Maximum public service duration, they must retire on that 
day. 

Therefore, retirement information should be prepared 
and provided to decision makers (i.e., retirement selection 
memmittee). this information should include a list of 
officers who reach the maximum public service duration or 
a list of officers who wish to retire and have satisfied 
the minimum requirements, or a list of officers who can 
no longer work in the Army. 

C. MAJOR REQUIRED INFORMATION IN PERSONNEL MANAGEMENT 

TO INCREASE WAR POWER 

The main functions of personnel management for the ROK 
Army have been described. Next, what information is needed 
meeanalyze, to investigate, to plan, and to apply in those 
functions is described. Information personnel managers may 
meauvest might include: 

l. List of all new officers for each source organization 
concerning scholarship, classification of home town, 
emily condition, health condition, completion rate of 


Beucation and training, etc. 


Aa 





wa location Of Occupation and classification of each 
rank based on source organization. 

3. The number of cadets or candidates who should be 
designated in the next year or at a specified year for 
aac SOUrce Organization. 

4. List allocation for each class of civilian school 
mor €ach personnel rank or all personnel. 

Peeisteallocation»of all officers with each rank who 
mave been graduated for each military education course. 

eeocreetian Of Some officers for some positions. 

ime octecGtionse: some officers ain bamited rank for some 
educational classes. 

S$. Summary of an officer's career from a certain previous 
rank up to the current rank. 

feeeGbist the data Characteristics of a person or a group 
(military unit) of personnel. 

meee clilocation of personnel service material for each 
Yank and for each military unit. 

meee resent an information list for promotion purposes 
for each rank and service branch, including career, result 
of fitness reports, education, rewards and punishment, 
health condition, and the order of promotion recommendation, 
orc. 

All of the information which may be required by personnel 


managers can not be described, because different managers 


ae 





request different information. Personnel managers might 
need information for their job in addition to that described 
above. 

D. ADVANTAGES AND DISADVANTAGES OF A DATABASE SYSTEM OVER 

Pele so youlkMS 

All of the information required by personnel managers 
are Statistical in nature and must be accurate. Because it 
mocime-Consuming to extract them, computerized systems 
are needed. File systems are usually used for extraction 
of some information in the ROK Army, but these have 
inefficiencies which could be covered by a database system. 
A database system has several important advantages over 
file systems for most enterprises. These are verified 
in Ref. 8 and Ref. 10 as described below. 

First, the data can be shared. This reduces the time 
needed to develop new systems or to respond to one-of-a-kind 
requests. In effect, more information can be obtained 
ieom existing data. 

The second advantages of a database system is the 
Paimination or reduction of data duplication that can lead 
Mewa tack of data integrity in conflicting reports. 

The third advantage is independent creation of programs/ 
data. Since each application program interfaces with the 
DBMS rather than directly with the database, changes to 


the database may be accomodated by changes to the DBMS 
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without any changes to the application programs. 

However, the DBMS may be expensive, typically, $100,000 
Or more to buy. Furthermore, the processor may occupy so 
much memory that additional memory must be purchased. 
However, these problems will occur only one time when a 


new database system is developed. 


mee ©6CONCLUSION 

In order to increase the war power of the ROK Army, 
it 1s essential that personnel management be performed very 
efficiently. However, to manually manage all Army 
personnel is a very tedious, complex, and time consuming 
job. Personnel management operations will be complicated 
more and more. Furthermore, personnel managers and decision 
makers will need more accurate and more statistical infor- 
Maeton. It 1S impossible to get all information with a 
manual system or file systems which are required by 
personnel managers in a short period of time. Some high 
and middle level officers of the ROK Army are very 
interested in DATABASE SYSTEMS. On the other hand, the 
number of officers who are working in middle and high level 
positions must be reduced to decrease the national defense 
expenditure. 

The database system has become an important tool for 
retrieving timely and accurate information and is expected 


to provide its user with the required information within a 
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Specified time. Almost all of today's DBMS were developed 
to manage large database systems. Therefore, a standard 
database system has to be developed for efficient 


personnel management in the ROK Army. 
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III. GENERAL OVERVIEW OF A DATABASE SYSTEM 


mee) 6LNTRODUCTION 
Terminology for database systems is still not standardized. 
Different database systems employ different words to describe 
the data [Ref. 7]. Therefore, confusion has arisen over the 
@escription of the database. However, it is to some extent 
accepted as conveying a more sophisticated concept than the 
Glder term "file". File processing systems are predecessors 
of database systems. They do not allow integrated processing 
[Ref. 8]. In order to develop a database System and to 
apply it, the general terminology and basic concepts must 
be understood by-users and designers. 
For the above reasons, this chapter begins with 
definitions of some of the basic terminologies, and then 
discusses architecture and user classification of a database 


system, and objectives of database system organizations. 


Pee DEFINITION OF BASIC TERMINOLOGY 
me vogical and Physical Data Description 
Descriptions of data and of the relationships between 
data are one of two forms: logical or physical [Ref. 7, 9]. 
Paysical data descriptions refer to the manner in which data 
are stored physically on the hardware, i.e., the physical 
database resides permanently on secondary storage devices, 


such as disks and tapes. However, logical data descriptions 
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refer to the manner in which data are represented to the 
mepiication programmer or user of the data. 

wee Data 

There are many alternate words used for describing 

data. A widely accepted authority on databases is the 
CODASYL Data Base Task Group (DBTG) [Ref. 7]. Generally, 
data is a description of phenomena in some fashion. In the 
following subsections and Figure 3.1, the words used to 


describe the application programmer's view of data are shown. 





a | ——— _ record 


database a 7: sae 


—- ~ 


I 


fea 
group of fields 


Figure 3.1. Terms Which Describe the Application 
Programmer's View of the Data 


3. Field (Data Item, Data Element) 
Apeteud 1S the smallest unit of named data. It may 


consist of any number of bytes. 


in 





feeecroupeor: Fields (segment, Data Aggregate) 


A group of fields is a collection of fields within a 
record which is given a name and referenced as a group. 

For example, a group of fields called DATE may be composed 
of the fields MONTH, DAY, and YEAR. 
59. Record 

A record is a named collection of fields or groups 
Oe fields. 

6. Database 

A database may be defined as a collection of records 
which have the same record type. 

7. Databases 

In most systems the term database does not refer to 
all the record types but to a specified collection of them. 
There can be several databases in one database system. The 
term databases is used for the collection of databases. 

8. Database Management System (DBMS) 

A DBMS is software that allows one or more persons 
to use and modify the databases. A major role of the DBMS 
mento allow the user to deal with the data in abstract terms, 
Paener than as the computer stores the data. In this sense, 
the DBMS acts as an interpreter for a (very) high level 
language. 

pe 6Patabase System 
A database system is a combination of databases, a 


DBMS, and an application system (if necessary). Figure 3.2 





shows a standard database system. The application system is 
collection of end-user application programs which are 


related in each view in Figure 3.3. 


application system 





Figure 3.2. A Standard Database 
system 


See ARCHITECTURE FOR A DATABASE SYSTEM 

Hae architecture is divided into three general levels: 
internal; conceptual and external [Ref. 9, 10]. Figure 3.5 
Shows the standard view-points regarding the three levels. 

Mimiliewne so a single database, which may be one of 
many databases using the same DBMS, is viewed at three 
M@mreerent levels. Only the physical database exists. The 
mmecpttal database 1S an abstract representation of the 
physical database, and the views are each abstractions or 
portions of the conceptual database. 
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internal 
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Figure 3.3. Standard View-points of a Database System 


Meee P TCAL USER CLASSIFICATION OF DATABASE SYSTEMS 

Three broad classes of users can be typically considered 
(Ref. 8, 10]. First, there is the APPLICATION PROGRAMMER. 
His/her responsibility is to write application programs that 
use the database. These application programs operate on 
the data in all the usual ways: retrieving information, 
creating new information, deleting or changing existing 


mit ormation. 
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The second class of user is the END-USER. He/She accesses 
the database from a terminal and may employ a query-language 
(Chapter V) provided as an internal part of the DBMS. Also, 
the user invokes a user-written or programmer-written 
epplication program (Chapter V) that accepts commands from 
the terminal and in turn issues requests to the DBMS on 
the end-user's behalf. Either way the user may again perform 
all the functions of retrieval, creation, deletion, and 
modification, although retrieval is the common function 


mor this class of user. 
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Bagure 5.4. An Example of DBA's Organizational 
Relationships 


The third class of users is the DATABASE ADMINISTRATOR 


(DBA). The DBA is the person (or group of persons) 





responsible for overall control of the database system. 
Figure 3.4 shows an example of the DBA's organizational 
relationships. The DBA's major responsibilities include 
the following areas: 

1. Deciding the information content of a database. 

The DBA decides exactly what information is to be 
held in the database to identify the entities of interest 
to the enterprise and to identify the information to be 
recorded about those entities. 

2. Deciding the storage structure and access strategy. 

The DBA must decide how the data is to be represented 
in the database and must specify the representation by the 
storage structure definition. 

3. Communication with users. 

It is the business of the DBA to communicate with 
users, to ensure that the data they require is available, 
and to write the external schemes. 

4. Defining authorization checks and validation procedures. 

Since the data is a shared resource, problems occur 
regarding who can do what to the data. The DBA must consider 
each shared data component and determine access and modifica- 
mom rights. 

9. Defining a strategy for backup and recovery. 

The DBA must define and implement an appropriate 

recovery strategy, involving periodic dumping of the database 


to a backup device and the procedure for reloading the 


by 





relevant portions of the database from the latest backup 
generation. 


6. Monitoring performance and responding to changes in 
requirements 


The DBA is responsible for organizing the system so 
as to get the performance that is "best for the enterprise", 
and for making the appropriate adjustments as requirements 
change. 

The ROK Army has many end-users for personnel management, 
but there is a lack of application programmers and DBA per- 
sonnel. Therefore, the ROK Army has to identify and train 
many personnel in computer technology who will work in 
computer operations or computer policy areas. Furthermore, 
most end-users do not have any knowledge of computer operations 
and database systems. Therefore, the ROK Army has to train 
personnel in computer operations who will work in personnel 
Management departments. Database system designers must 


consider these situations. 


Meee lie OBJECTIVES OF DATABASE SYSTEM ORGANIZATIONS 

A database system should be a repository of the data 
needed for an organization's data processing. That data 
Should be accurate, private, and protected from damage. 
iiessystem should be designed so that diverse applications 
with different data/information requirements can employ the 
data. Different end-users have different views of data 


(section D) which must be dervied from a common overall 
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@ata structure. In order to achieve these user requirements 
and others, the following objectives are considered by 
database system designers [Ref. 7]. 

1. THE DATABASE IS THE FOUNDATION OF FUTURE APPLICATION 
DEVELOPMENT. It should make application development easier, 
Sieaper, faster, and more flexible. 

2. THE DATA CAN HAVE MULTIPLE USES. Different users 
who perceive the same data differently can employ them in 
different ways. 

3. CLARITY. Users can easily determine and understand 
what data are available to them. 

4. EASE OF USE. Users can gain access to data in a simple 
fashion. Complexity is hidden from the users by the DBMS. | 

See FLEXIBLE USAGE. The data can be used or searched 
in several ways with different access paths. 

See CHANGE IS EASY. The database can grow and change 
Without interfering with established procedures for using 
the data. 

7. LOW COST. The cost of storing and using data, and 
the cost of making changes, must be as small as possible. 

8. LESS DATA PROLIFERATION. New application needs 
may be met with existing data rather than creating new 
meres, thus avoiding the excessive proliferation in today's 
tape libraries. 

9. PERFORMANCE. Data requests can be satisfied with 


Speed suitable to the usage of the data. 


34 





10. PRIVACY. Unauthorized access to the data will be 
Beevented. The same data should be restricted in different 
ways from different uses. 

11. AVAILABILITY. Data should be available to users at 
the time when they need them. 

len RELIABILITY. Almost all information/data for 
personnel management 1S very important to both individual 
personnel (eg. for promotion, for new assignment, etc.) and 
group personnel. The information which is derived from 


database processing must be very reliable. 





IV. DATABASE DEVELOPMENT 


A. INTRODUCTION 

There are many ways in which a database can be designed. 
miren principles should be applied in selecting a database 
model? Which database model should be selected to develop 
the most efficient database system for ROK Army personnel 
management? Which data items should be incorporated in a 
database? Which tecnique should be applied to design data- 
bases using a selected database model? The ultimate 
objectives of database systems organization, discussed in 
Seapeer III, are to make application development easier, 
@meaper, faster and more flexible. These objectives must 
be considered by the database designers in designing a database 
system. The considerations for database model selection are 
ease of use, efficiency of implementation, and matching the 
meeneture Of real data. Ihe relational database model is 
the best database model for ease of use [Ref. 7, 9, 10, 11], 
maemecnough tt has some potential inefficiencies. These 
inefficiencies can be eliminated using query optimization 
discussed in Chapter V. End-users who work in the depart- 
ment of personnel management usually use many tables for 


melrection of data. 





B. DATABASE MODELS AND A DATABASE MODEL SELECTION 

For data to be useful in providing information, they 
need to be organized so that they can be processed efficiently. 
A database model is an abstraction device. It is a pattern 
according to which data are logically organized. It consists 
of named logical units of data and expresses the relation- 
ships among the data as determined by the interpretation of 
a model of the real world [Ref. 11]. 

In data modeling, data must be organized so that they 
represent as closely as possible the real world situation. 
Many different models exist, such as relational, network, 
mienarchical, entity-relationship, binary, semantic, and 
the infological data model. However, only three data models 
are well known (relational, network, hierarchical) and are 
most readily available [Ref. 9, 11]. It is desirable to 
select one database model which is available in a commercial 
system to apply to the ROK Army personnel management. To 
select one database model among these, the main criteria 
by which they should be judged to achieve the objectives 
of a database system organization are described below. 

1. Ease of Use (Simplicity) - It is felt that the less 
complex a data model is, the easier it is for people to 
understand and use it properly, The principal costs may 
be the time spent by the programmer writing applications 
programs and by the user posing queries. A model that makes 
accurate programming and the phrasing of queries easy and 


Simple is desired. 
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2. Efficiency of Implementation - When databases are large, 
the cost of storage space and computer time may dominate 
the total cost of implementing a database system. 

5S. Matching the Structure of the Real Data - Selecting 
a database model involves matching the structure of real 
data to capabilities of the database model. For example, 
if the data are naturally hierarchical, a hierarchical data- 
Base model may be the best choice for the application 
[Ref. 11]. Such a matching may also be desirable to minimize 
retraining of the users and to accommodate current data 
collection and entry. 

Using the criteria of ease of use, there is no doubt 

immat che relational model is superior [Ref. 7, 8, 9, 10, 11]. 
It provides only one representation of relationships (tables) 
that programmers or users must understand. Moreover, there 
mmcerich, high level languages for expressing queries on 
data represented by the relational model. On the other 
hand, the network model requires an understanding of both 
record types and links, and their interrelationships. 
Similarly, the hierarchical model requires an understanding 
of the use of pointers (virtual record types) and has the 
same problems as the network model regarding the representation 
of relationships. When the potential for efficient implemen- 
tation is considered, the network and hierarchical models 


Score higher marks than relational models [Ref. 9]. 





Unfortunately, the ROK Army has many problems regarding 
the operation of a database system in all user groups, as 
Meseribed in Chapter II. Therefore, the relational database 
feel 1S MOSt appealing because of its ease of use. Even 
though the relational model has some inefficiencies, the 
storage space and computer time can be reduced using methods 
such as multilist, normal forms (Chapter IV), and query 
Optimization (Chapter V). These are available in system R 
which was developed by IBM [Ref. 9]. 

tmecie Ormet Nand, even though individual personnel 
mata for ROK Army personnel management is nierarchical, 
individual personnel data can be constructed as relational; 
most users need statistical information rather than 
individual personnel information to analyze and to plan for 
personnel management; and almost all data formats which 
ame used in the ROK Army are tabular forms. These situations 
can be matched to the relational database model. Therefore, 
the relational database model appears to be the best for 


ROK Army database system operations. 


mee SL RUCTUEE OF A RELATIONAL DATABASE MODEL 

The data structuring tool used by the relational database 
model is the relation. A relation is simply a two dimensional 
table. Columns of a relation are referenced as attributes. 
Each row of the relation is a tuple. A relation that has 


n columns or n attributes is said to be of degree n. Each 





attribute has a domain, which is the set of values that the 
attribute may have. A relation of degree n has n domains, 
not all of which need be unique. To differentiate between 
attributes that have the same domain, each is given a 
unique identifier called an attribute name. Tuples can be 
inserted, deleted, and modified in database relations 


feet. 7, 8, 9; 10, 11]. 


Ee RON ; 


nO Sates 75-00162 | Hong, dae sik | 


| colonel | 54507 6 ZO bo Park, | Park, kil dong dong | 
9877655 65544 Kim, oe Su 


Figure 4.1. An Example of a Relation 





In Figure 4.1, the RELATION is PERSON, and the RANK, SSN, 
MSN and NAME which represent rank of person, social security 
mumber of person, military series number of person and name 
Sieperson, respectively, are called attribute names. Each 
memain Of attributes can be limited using a specified number 
of characters, numeric or alpha-numeric. "Hong, Dae sik” 
1s a value of attribute "NAME" and is included in the domain 
"NAME". On the other hand, one semantic interpretation 


that can be applied to a relation is to make each tuple 
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Serrespond to a particular entity. A person is an entity, 
and all persons who are officers and working in the ROK Army 
is an entity set in Figure 4.1. 

Relational databases are specified by a relational 
schema which consists of one or more relational subschemas 
(scheme). A relational subschema is a listing of a relation 
name and its corresponding attributes. However, a relational 
schema and a relational subschema correspond to the databases 
and a database in a database system, respectively. Figure 4.2 
represents an example of a relational schema for ROK Army's 


personnel management. 


PERSON (rank, ssn, msn, name) 


FATHER (father's name, father's ssn, msn, 
profession, address, phone #) 


SCHOOL (msn, name of school, start date, end date, 
degree} 


VirrriARyY SUNTL {msn of an officer, unit name, 
commander name, location) 


Figure 4.2. An Example of a Relational Schema 


The specification "PERSON (rank, ssn, msn, name)" is an 
example of a relational subschema, and a relational subschema 
can be used to represent an entity type in relational 
databse models. 

Within a given relation there are one or more attributes 


With values that are unique within the relation and thus can 
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be used to identify the tuples of that relations This is 
called the primary key for that relation. However, not 

every relation will have a single attribute primary key. 

Some relations will have some combination of attributes that, 
when taken together, have the unique identification property. 
The model may also use a key which does not identify a unique 
tuple, but which identifies all those tuples which have 


that certain property. This is called a secondary key. 


D. FUNCTIONAL DEPENDENCY AND DECOMPOSITION 

The major direction of most database designers effort 
fiemero ODtain an accurate schema. dhe concept of what is 
meant by a 'good''/"better" schema, and the associated condi- 
tions, must be formalized. 

Let X and Y be the attributes of a relational subschema, 
Feeand let £ be a time-varying function such that f is a 
function from the underlying domain of X to the underlying 
domain of Y (written f : X——>Y). In the precise mathematical 
sense, £ is not a function because it is allowed to change 
feretime. ff f is thought of as a set of ordered pairs 
mex, y) Mrm voy imryY |, then at every point in time, for 
omeoaven Value of x in X there is at most one value of y in 
Y associated with x. To distinguish f from a mathematical 
mimecioOn, it is called a functional dependency [Ref. 7, 9, 
10, 11]. If f : x —-»Y, then Y is said to be functionally 
dependent on X, and X is said to functionally determine Y. 


X—><——> YY means that Y is not functionally dependent on X. 
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In order to derive a good/better schema, it is important 
to be able to derive all the functional dependencies, f. 
The inference rules (axioms) which can be used to derive 


implicit functional dependencies are as follows [Ref. 9, 11]: 


FDI (Reflexivity) : If Y included in X, then | cmceact co 
PD2 (Augmentation) : If Z included in W and X-——— Y, 
then XW ———>YZ. 
FD3 (Transitivity) : If X——— Y and Y—— »Z, then 
merge 
FD4 (Psuedo-transitivity) : If X——-Y and YW-——Z, 
then XW———>Z. 


hoo (Decomposition) : If X 





YZ, then X——— SY and 
X————>Z. 


(where W, X, Y, and Z are subsets of the attributes) 


Generation of all functional dependencies is very time 
consuming, because usually there are many functional 
dependencies in a subschema. Functional dependencies can 
be used to evaluate the schema and to decompose it into a 
better schema. Other reasons have also been suggested why 
decompositions are necessary [Ref. 9, 11]. In Figure 4.2, 
the relational subschema 


MILITARY-UNIT (msn of an officer, unit name, commander 
name, location) 


may have the following anomalies and redundancy in manipulation: 
1. Update Anomaly - The change of commander name in a 
military unit necessitates a series of changes of commander's 


name. 
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2. Insertion Anomaly - When an officer is assigned to 
eemilitary unit, the commander's name and location of unit 
mast be included. 

3. Deletion Anomaly - When an officer is transferred to 
another military unit, any military unit information will 
cease to exist. This can be considered an anomaly if it 
is desired to retain important, long-range information 
epout the unit. 

4. Redundancy - The commander's name and location of unit 
are repeated in many tuples. This redundancy causes 
problems, not only because it is wasteful (storage), but 
also because redundant data must be consistently maintained. 

These problems can be avoided by decomposition. In the 
above example, the anomalies can be eliminated by breaking 
the relational subschema into two relational subschemas: 

PERSONNEL-ALLOCATION (msn, unit name) 

MILITARY-UNIT (unit name, commander name, location) 
mimtehne decomposed subschema, PERSONNEL-ALLOCATION and 
MILITARY-UNIT are isolated and related only by specifying 
Gieminit mame im which the officer works. This decomposition 
MemnoOt arbitrary. It is based on the two functional 
dependencies msn———»unit name, and unit name ——» commander name, 
location. The decomposition isolates these two dependencies 
mieseparate relational subschemas. As a result, they do 
not interface with each other. In addition, the separate 


subschemas are considered better than the original subschema 
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when the natural join (described in Chapter V) of two 
subschemas is equivalent to the original subschema. There- 
fore, all of the rules (axioms) and properties above will 
be used to derive a "good"/"better" schema in the following 


sections. 


Hee OCHEMA DESIGN 

A relational schema using all of the results and theories 
which are derived from previous sections, and using the 
functions of departments of personnel management are designed 
mie tnis section. 

im Keguirements Amalysis 

The first step of schema design is requirement 

analysis. This step consists of a high-level analysis of 
the function of an organization (i.e., departments of 
personnel management in the ROK Army). The functions of 
departments of personnel management and required information 
Pemcmotven in Chapter [f. The purpose of this step is to: 


a. Gain familiarity with the area of the organization 
to be modeled. 


b. Determine the information requirements of the organization 
Without regard to constraints other than the way in 
which an organization does business, and 


c. Represent these requirements via some formal modeling 
technique. 


To gain familiarity with the organizational area, 
the organization must be understood in terms of its goals and 


the strategies it uses to achieve these goals. To determine 
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the information requirements, data on processes in the 
organization must be collected. Finally, data modeling 
techniques are used to formally represent the information 
requirements. 

Information requirements are collected from users 
at all levels in the organization. In most organizations 
at least three levels that provide data can be identified: 
top management, middle management, and operations management 
[Ref. 11, 12]. From top management, information on the goals 
and objectives of the organization can be obtained, along 
with strategies and methods for managing the implementation 
of the strategies. Middle management provides more detailed 
Mobicies and constraints, and provides data about required 
response time, reliability, security, and privacy, etc. 
Finally, operations management provides more specific infor- 
mation, such as names, sizes, number of occurrences, integrity 
constraints, reliability, security and privacy of data. 

They also provide information on data usage, volume, frequency 
Seeoccurrence of transactions, priority of transactions and 
Sequencing with other transactions. 

The main purpose of this step is to understand users' 
need. Subsequent steps of the schema design process can 
transform these needs to subschemas according to the 
relational data model. This approach to requirements analysis 
produces a business model (Appendix A) as an outcome of this 


step. 
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Qe ntepratlonsot Required Data Classes 


In Appendix A, each data class in a function 
represents a view of the subschema/schema. These views 
are then integrated to form a subschema which shall be 
mitegrated to form an enterprise description which describes 
the entire schema. This description (Appendix E) is used 
primarily for communication between the users and the schema 
designers. 

Different users in different functional areas usually 
require different data (attributes) in each data class. 
Thus, common entity types must be extracted from the data 
MieaissesS through the integration of data in all functional 
areas for each data class. The following questions must be 
answered regarding the entity types 


a. What are the entity types described by each data 
wlecsein a@ LunGcElonal area? 


ieee What 1S the appropriate name for each entity type? 
c. What is the meaning of each entity type? 
Gee What attributes are of interest for each entity type? 
e&. What is the appropriate name for each atribute? 
mee What 1S the meaning of each attribute? 
Based on these questions, entity types have been 
Specified for each data class (Appendix B). An entity 
type defines what it represents and specifies its associated 
attributes. 
Entity type identification is an iterative process. 
The description of an entity type may change many times 
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before everyone agrees that it is right, or may change during 
the analysis of normal forms or design of the data dictionary 
(Appendix E) which is the final documentation for each 
entity type. 

S. Analysis and Design of Normal Forms 

Functional dependency and its axioms, decomposition, 
and original entity types were described in previous sections 
and in Appendix B. The original entity types have many 
anomalies which should be eliminated to realize an acceptable 
schema. Anomalies are caused by certain unwanted functional 
dependency structures. These structures can be avoided by 
forcing some restrictions on the allowed functional 
dependencies in a relational subschema. 

Relational subschemas that are satisfied by the 
mestrictions are said to be in normal forms [Ref. 7, 8, 9, 
10, ll]. Though there are five normal forms, only three 
will be considered. Even though the others can eliminate 
redundancy, it becomes too complex to manipulate the 
database system derived from five normal forms and increases 
the execution time. A relational subschema is converted 
into a normal form relational subschema by decomposition. 

Consider a relational subschema, R, and a set of 
functional dependencies, F. A superkey, X, of R is a set 
of attributes, X, of R such that for every attribute, A 
of R, X——— A. A key of R is a superkey which is nonredundant. 


mmeatcribute of R is prime if it participates in a key. 
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Since a relation can have many keys, they are sometimes called 
candidate keys. An attribute or a collection of attributes, 
B, can be said to be fully functionally dependent on another 
collection of attributes, A, if B is functionally dependent 
feat, as opposed to part A. Finally, attribute C is 
transitively dependent on attribute A if there is an attribute 
B such that: A-—— 9B, B——»C and B—<—>A. 

Relation, R, is in first normal form if every 
meert bute 1S a simple attribute. That is, there are no 
composite attributes in R. 

Rolston ke is In second normal form if 1t 15 in first 
normal form and every nonprime attribute of R is fully 
functionally dependent on the keys. 

Looton wh seine third normal form.1f it 1s in 
second normal form and it has no transitive dependencies 
among nonprime attributes. 

Even though the three normal forms are analyzed 
and designed, only the entity types which are designed with 
meaird normal form are shown in Appendix C. This job is 
meme Consuming and difficult, but 1s a very important step 
in database design to accomplish the objectives of database 
System organizations efficiently and to reduce some 
inefficiencies in relational database models. Some subschemas 
which can be manipulated by a manipulation language 
(Chapter V) can be eliminated, and some subschemas which 


have almost the same attributes and exactly the same 
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immetroOnalwdependencies Can be combined into a single 
subschema through the normal forms design and analysis. 


These phenomena are discussed in Appendix C. 


4. Analysis and Design of Relationships Between 
Elreeeey: my pes 


The result of the normal form design step is a 
Meee Or entity types, entity names and their attributes. 
If some complex information from a database system is 
required, relationships are needed. To help identify 
relationships between entity types, the following questions 
emee posed. 

1. For each function, what are the known correspondences 
(relationships) between entity types associated with the 
Pome t1On? 

2. What is the appropriate name for each relationship 
De ! 

meeLS the relationship type expressible in closed form 
using the attributes of the entity types (e.g., is PERSON 
fee SseEN PROMOTED (in Appendix D) true when military 
Serial number in PERSON equals military serial number in 
PROMOTION LIST)? 

4. What is the meaning (semantics) of each relationship? 

As a result, there are many relationships between 
two Or more entity types in each function. Some sample 
relationships are shown in Appendix D. Fortunately, all 


G6tethe relationships are exoressible in closed form using 
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attributes of the entity types (e.g., military serial number, 
rank, branch, ...). Relationships are not grouped for each 
function in Appendix D, because they overlap with many 
mimetlons and data classes as shown for each function in 


the business model (Appendix A). 


F. CONSTRAINTS ANALYSIS AND ASSIGNMENT 

Finally, to complete the database design step, the 
@enstraints on the attributes, entity types, and relation- 
aes must be identified. Constraints must be subjected 
to user scrutiny. Constraints are identified by asking 
@aestions such as: 

1. What 1s the domain of values for each attribute 
woo 1S Military serial number between a 5 and 9 digit 
number) ? 

2. What are the known functional dependencies between 
Merributes of each entity type? 

Pinat are the keys for each entity type? 

feet hat is the mapping property of each relationship 
(e.g., one to one, one to many, many to many)? 

some of the constraints (functional dependencies and 
keys) are identified in Appendix C through normal form 
analysis. The mapping property of each relationship 
type 1s included in Appendix D, and domain constraints are 
included in the data dictionary (Appendix E). 

It is difficult to arrive at a set of constraints that 


mepresent tne application and is consistent and feasible, 


Sy 





because some forms of the constraints are difficult to under- 
stand are prone to misunderstanding and errors. There- 
fore, they must be reevaluated during the database test 


Seep . 


G. DATABASE TESTING 

The testing stage may require up to half of the total 
effort. Testing may be required both in each development 
step and before databases are implemented. Inadequately 
meeanmed testing often results in woefully late deliveries. 
A domain is the set of permissible real data to a database, 
and a test is a subset of the domain. 

A testing criterion specifies what is to be tested. A 
general testing criterion may include: 

1. Review all of the questions and analyses in the 
development process. 

2. Compare the data dictionary and the capacities of 
mae Object DBMS. 

A testing is complete if the test meets all the require- 
ments of the test criterion, and databases are reliable if 
every discovered error is reveaied by each complete test 
[Ref. 15]. Reliability may be achieved in three ways: 
walkthrough, documentations reading, and error checking 
programs. 

A walkthrough is a user review to discover errors in 


the data dictionary and subordinate documentation. This 
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is scheduled periodically for all users in each development 
step and is intended to detect errors, not to correct them. 

A very effective version of the walkthrough is documentation 
reading. Second designers review the documentation, including 
m@emdata dictionary. This technique frequently turns up 
errors when the second reader, failing to understand some 
Bemects Of the documentation, asks the designer for an 
Sxolanation. 

Emnor checkine programs are a part of the end-user 
application system to enhance reliability and validity during 
Micmenrecation, insertion, and modification in a specified 
mitabase. these programs check values of each attribute 
which has limited values (e.g., attribute RANK has limited 
values), and notify users of errors when users create a new 
database, insert records into a database, or modify some 
miolas in a record. These programs will be included in an 


muemuser application syStem in the next chapter. 


fee CONCLUSION 

Conceptual databases of a component of a database system 
developed for ROK Army's personnel management are described 
iieenis Chapter. 

the database system organization objectives provide a 
guide for all of the database development steps, including 
selection of a data model and database design technique. 
The relational database model was selected to develop the 


most useful database system in the ROK Army environment. 
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The business model was used to gain familiarity with the 
organizational area and to integrate similar attributes into 
a data class in many different functional areas. The normal 
forms (lst, 2nd, 3rd), those based on functional dependencies, 
are applied to reduce the inefficiency of the relational 
data model in storage space and to eliminate anomalies and 
redundancy. The other normal forms (4th, 5th) were not 
Peeled In Onder to maintain simplicity during the complex 
imrormation extraction. Relationships, which are expressible 
in closed form using the attributes of the entity types, and 
constraints are developed in order to help user understanding. 
Finally, a database description (data dictionary) which 
communicates between database designers and users has been 
m@eveloped. 

Pie saocumentation, including the data dictionary, must 
be tested in each database development step before the 
database is operational. This database development method 
1s a technique to achieve the objectives of database system 
Organizations for ROK Army's personnel management. This 
technique enhances simplicity of the process to database 
designers. Users may understand the database design steps 
and database itself very easily. Furthermore, users may 


manipulate the database by themselves. 
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VN OononheareLICATION SYSTEM DEVELOPMENT 


A. INTRODUCTION 

Up to now, the main functions of the ROK Army's departments 
of personnel management and some important theories which 
are relevant to database system development have been 
discussed. Also, databases based on the relational database 
model have been described. In this chapter, an efficient 
end-user application system for any DBMS which uses a 
relational database model is discussed. 

Query languages or end-user application programs are 
used to extract information from the databases. The query 
languages for the relational data model usually break down 
into two broad classes: algebraic languages and predicate 
calculus languages. These abstract query languages are not 
implemented exactly in any existing DBMS, but they serve as 
a benchmark for evaluating existing systems. Since each of 
the two abstract query languages is equivalent in expressive 
power to the other [Ref. 9], only the algebraic query 
language will be discussed in this chapter. A real query 
language provides the usual capabilities of the abstract 
languages, as well as additional capabilities. 

Tre end-user application programs are a collection of query 
languages and resemble a general program using a very high 


mover language to extract complex information or make 





frequent/periodical queries (daily, weekly, monthly,...). 

As discussed in Chapter IV, the relational database model 
has some inefficiency of implementation in storage and 
execution time. The inefficiency should be reduced by 
database system designers as much as possible. The database 
has been designed using normal forms to eliminate the 
anomaly and redundancy. Also, designers must attempt to 
reduce execution time using techniques such as query 
Speimization. 

In order to achieve the objectives of the database 
Systems organization, software engineering goals — under- 
Standability, reliability, efficiency, modifiability — 
will be considered. To address software engineering goals, 
top-down design methodology and structured programming will 


Besapplied as tools. 


B. CAPABILITIES OF AN ABSTRACT ALGEBRAIC QUERY LANGUAGE 

There are five basic operations, as well as a few 
additional operations, that may add to the set of operations 
in the algebraic query languages. The five basic operations 
are: 

i Union - The union of relation R and S, denoted R U S, 
mepeme Set Of tuples that are in R or S or both. The union 
Seemation 15 applied only to relations of the same degree. 

2. Set Different - The difference of relations R and S, 
wemeted R - 5S, 1s the set of tuples in R but not in S. 


R and S must be of the same degree. 
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5. Cartesian Product - Let R and S be relations of degree 
r and s, respectively. The Cartesian product of R and S, 
denoted R x S, is the set of (r + s) - attributes whose first 
r attributes are from a tuple in R and whose last s attributes 
are from a tuple in s. 

4. Projection - Let the relation R have four attributes, 
Meted by R {aa, bb, cc, dd). Then the projection aa and bb 
of R, denoted R [aa, bb], means remove attributes cc and dd, 
and rearrange the remaining attributes aa and bb to form 
anew relation, S (aa, bb). 

5. Selection - Let F be a formula involving (i) operands 
that are constant or attributes (ii) the arithmetic comparison 
operators <, =, >, <=, >=, and /=, (iii) and the logical 
@eenators ‘and, “or and "not". The selection of F, denoted 
Sp(R), is the set of tuples in R which satisfies the formula F. 

some additional operations are intersection, quotient, 
join and natural join in abstract algebraic query languages. 
The join is the composition of Cartesian product and selection 
and may require excessive time for execution. The natural 
jOin, denoted (R X S&S), is important to prove that two 
or more decomposed subschemas are equivalent to the original 
subschema, as discussed in the previous chapter. To computer 
(R | X| eeersocmconpute (Ro xX S). Next, for each attribute 
A that is named in both R and S, select from (R X S) those 
tuples whose values agree in both R.A and S.A. Finally, for 


Edeneattribute A, project out the column S.A. Figure 5.1 
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Figure 5.1. Operation of Natural Join 
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Shows the operation of natural join using the example of 


decomposition which is given in the previous chapter. 


C. DATA MANIPULATION LANGUAGE 

The operations of algebraic query languages were 
previously discussed. The notation for expressing queries 
is usually the most significant part of a data manipulation 
language. Data manipulation languages usually have operations 
beyond those of query languages. Of course, all data 
manipulation languages include insertion, deletion, and 
modification commands, which are not part of the query 
languages. Some additional operations are frequently available 
such as arithmetic, assignment and print commands, aggregation 
Seetunction (eg. average, sum, total, min, max,...) and so 


On. 


Dee QUERY OPTIMIZATION 

High level query languages allow the writing of queries 
that may take a great deal of time to execute. Execution 
time can be significantly reduced if the query language 
meeceSsOr rephrases the query before executing it. Such 
improvements are commonly called optimization. Programmers 
might ask why certain queries take a long time to execute. 
The greatest offender for query languages based on the 
relational model is the query that involves a Cartesian 
product, join or natural join. If programmers apply some 
Strategies to a given query, they can reduce the execution 


time. The general strategies are [Ref. 9]: 
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ime eben torm selection as early as possible. 

2. <A Cartesian product followed by a selection. 

3. Look for common subexpressions in an expression. 
4. Cascade selections and projections. 


5. Combine projects with a binary operation that preceeds 
Ou rollows it. 


6. Combine certain selections with a prior Cartesian 
pueGguer to Make a join. 


Programmers should attempt to move selections and projections 
as far down the parse tree of the expression as they can, 
although they want a cascade of these operations to be 
organized into one selection followed by one projection. 

They should also group selections and projections with the 
preceding binary operation, such as union, Cartesian product, 


@eeset difference, where possible. 


Peet RANSACTION PROCESSING ANALYSIS 

In order to design application programs, designers have 
to analyze the transaction processing of each organizational 
area with respect to the database. This analysis specifies 
mieuts and outputs required, but does not involve the 
feeeitic steps to obtain the output. All current and projected 
Biamsactions are included. For each trasnaction designers 
identify its nature (e.g., retrieval, update), its frequency, 
its origin (functional area), and its purpose. 

To help identify requirements for supporting transactions, 


Some of the relevant questions to ask are: 
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1. What transactions are required by each functional area? 


eevee entity types and relationships are involved in 
each transaction? 


3. What kind of access is required by each transaction 
(e522. retrieval, update) ? 


4. What is the frequency of each transaction (e.g., 
daily, weekly, monthly,...)? 


Bees What 25 the processing priority of each transaction? 
Seeewiat reports are needed? 

7. What is the format of each report? 

8. What security requirements are important? 

The result of this analysis is a list of all transactions. 
Pescample list of some transactions, which are processed by 
meems in ROK Army’s departments of personnel management, is 
Poem in Appendix F. The list, because of its usefulness 
for design of an end-user application system, will be used 


in the next section. 


fee oro LEM DESIGN 
i, Generale vesten Concept 
In the end-users application system design stage, 
S@emalecorithms are developed, and the overall structure of 
the database system takes shape. The application system 
must be divided into small parts (modules), each of which 
meene responsibility of an individual or a small organizational 
area. Each such module must have its function and purpose 
defined. As submodules are specified, they are represented 
in a tree diagram showing the nesting of the system's 


components. 
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Because the solution may not be known when the design 
stage begins, decomposition into small modules and submodules 
may be quite difficult. A common problem is that the 
designer of an application system often does not know exactly 
what end-users want. Each transaction processing analysis 
may guide the solution to this problem. In this stage, 
software engineering goals must be considered in order to 
achieve the objectives of the database system organizations 
such as low cost, simplicity (comprehensibility), high 
performance, privacy and reliability. 

Top-down design can be related to structured 
programming, which has been erroneously called "gotoless" 
programming [Ref. 15], which is more efficient than "goto" 
programming [Ref. 14 and 15]. Top-down design has been 
proposed as a methodology for reducing the complexity of 
me e-ton. Ihe goal of top-down design is to minimize logical 
sores and inconsistencies through structural specification 
of the development process. System design consists of a 
sequence of a refinement steps. Therefore, although other 
design methodologies could be used, top-down design shall 
be applied. 

eee neliminary Design 

In the top-down design, a subroutine is first 
formulated as a single statement, which is then expanded 
into one or more of the data manipulation language statements 


described in a previous section. 
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ices Omnicom clininary adesion Step, Figure 5.2 
shows a baseline hierarchical diagram of an application 
system for end-users in the ROK Army's departments of 
personnel management which includes an error checking program 
previously described. Each transaction process described 
Mimene previous Section affects the selection of levels 
and modules in the baseline diagram which is based on functions 
of each operational area. 

Since different users need different information, 
application programmers have to modify the existing 
application programs or append new application programs to 
Miemexiscting system for any specified functions and purposes 
when the database system 1S operating. 

Since database security iS very important in the 
military, the DBA can include authorization check statements 
in each module. Furthermore, the DBA can store frequently 
used databases on high speed secondary storage. Therefore, 
this hierarchy of the application system should result in 
an increase in security, simplicity, modifiability, 
Menrormance, and reliability. 

eee Decalled Design 

For each level and module, each statement which is 
Written with the abstract algebraic query language is 
expanded in increasingly greater detail until the resulting 
description becomes the actual source language program in 


a selected DBMS. In order to reduce the execution time, 
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Figure 5.2. A Baseline Diagram for an Application System 
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the designer must consider query optimization before the 
actual source language is applied. 

The premise of structured programming is to use a 
small set of simple control structures with simple proof 
Tules. A written program then is built by nesting these 
Statements within each other. This method restricts the 
number of connections between program parts and thereby 
improves the comprehensibility and reliability of the program. 
The if-then-else, while-do, and sequence statements are a 
commonly suggested set of control structures for this type 


Geeprogramming [Ref. 13 and 16]. 


See otolEM TESTING 

The basic requirement for application systems is correct- 
eo. A program is correct 1f the output satisfies the output 
requirements for every input dictated by the input require- 
ments. Since the number of possible inputs is usually large, 
checking program correctness by examining the program inputs 
and outputs is not always feasible. In most cases, a program 
1s tested by a set of "representative" inputs. If the 
Smeets Corresponding to this set of inputs are correct, the 
program becomes operational and is released for general use. 

Since testing can only indicate the presence of certain 
Types Of errors, it is impossible to estimate the number of 
errors remainding in the system. Testing can not guarantee 


beemam Correctness. For these reasons, the reliability 
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Pero wtame1s @detined as the probability that the next invocation 
of the program is correct. A program which is correct with 
respect to tests performed on a few selected relations 

Can be considered extremely reliable if the inputs tested 
constitute 99.9 percent of all inputs to the program [Ref. 16]. 
It may be impossible to apply this definition to the very 

large databases. Thus, Ref. 16 suggests top-down design 

and structured programming as software development tools, 

and these have been applied already. 

Well organized system testing can improve the reliability 
of the program and improve user confidence, which are the 
Objectives of most testing. In order to improve the 
reliability and user confidence, the test plan should be 
designed early and most of the data should be specified 
during the design state. Testing is divided into three 
distinct operations [Ref. 13]. 

1. Module Testing subjects each module to the test data 
Supplied by the programmer. 

2. Integration Testing tests groups of components together. 
Eventually, this procedure produces a completely tested 
system. This testing frequently reveals error missed in 
module tests. 

3. System Testing involves the test of the completed 
system by an outside group. The independence of this group 


femamportant. 
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In each operation, the programmer should check that: 

1. Every statement has been executed at least once by 
the test data. 

[ee avery path through the program has been executed at 
least once by the test data. 

Be ror each specification of the program, test data is 
used to determine whether the program performs the particular 


beecitication correctly. 


H. CONCLUSION 

A end-user application system of a component of a 
database system developed for ROK Army's personnel management 
are described in this chapter. The end-user application 
system includes many application programs which are required 
for extraction of users' required information, creation of 
new databases, or deletion and updation of existing databases. 
Transaction processing of each functional area has been 
mealyzed before the system is designed in order to help 
the designer's understanding. This analysis specifies 
what the system is to do, but does not include how the 
Syoecem 15 to do it. 

The software engineering goals are considered to achieve 
the objectives of database system organizations. To address 
software engineering goals, top-down design methodology, 
and structured programming technique are applied as tools, 


and a baseline hierarchical diagram of the system is developed. 
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The premise of structured programming is to use a small set 
feeotmple control structures. Abstract algebraic query 
languages are applied in the preliminary design step. Query 
optimization techniques must be considered before actual 
source language is applied in the detailed design step 

in order to reduce execution time, which is an inefficient 
element in the relational database models. 

System testing is a tremendous job. The top-down design 
methodology and structured programming technique can decrease 
the amount of testing because they restrict the number of 
Semmections between program parts. Well organized system 
testing can improve the reliability of the system and improve 
ser confidence. Thus, the test plan should be designed 
before the testing step and most of the data should be 
specified during the design stage. Testing can enforce the 
module testing, integration testing, and system testing in 
a stepwise manner. 

ies development process of an end-user application 
System may achieve the objectives of database system 
organizations and may increase simplicity of the system 
wevelopment process for system designers. As a result, 
users can be convinced that "the database system is best 


in all systems for personnel management". 
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VI. CONCLUSIONS AND RECOMMENDATIONS 


The ROK Army personnel management is a complex and time 
consuming job and needs very accurate information to increase 
war power. Manual systems can not reduce national defense 
expenditures and make it difficult to obtain accurate 
information from all personnel in the Army. Thus, the Army 
needs a computerized personnel management system. Many 
file systems can be operated, but a database system is more 
powerful than the file system approach. Database processing 
can increase end-user productivity, decrease staff, enable 
work to be done more efficiently, and permit end-user 
management more authority and responsibility. 

The objectives of database system organizations can be 
established before the system development begins. Relational 
database models will be the most useful in the ROK Army's 
end-user environment, because this model gives structure 
independency for databases and high level languages for 
queries. Normal forms and query optimization techniques 
maeoe applied to décrease inefficiency of the relational 
database model in the system design stage. Furthermore, 
databases which contain the personnel data can be divided 
into smaller databases by using branch or rank in order to 
decrease execution time and increase security, if necessary. 


All data should be collected from military officer personnel 
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records and regulation books. However, all data can not be 
collected from personnel records which are currently used 
in the Army. Thus, the format of personnel records must be 
changed. The number of databases and the amount of data 
for each database will depend on the unit size (e.g., the 
Army Headquarters may require much larger databases than 
the other units). An end-user application system must be 
developed, because the end-users who are working in the Army 
have very little knowledge of database system operations and 
Memeodically require statistical information derived from the 
data. The software engineering goals must be considered, 
and top-down design methodology and structured programming 
techniques should be applied as tools. The application 
System for each unit is dependent on unit size and unit 
characteristics (i.e., Army H.Q. needs application programs 
to extract more complex and more aggregated information 
than the other units in order to increase group effectiveness. 
On the other hand, divisions need application programs to 
extract simpler and more individualized personnel information 
in order to increase individual personnel effectiveness). 
Software life cycle considerations guided the 
development process. This process can be applied to develop 
database systems for the other departments (G-2, G-3,...). 
The developed database system can be implemented any way 
for personnel management for all departments of personnel 


management in the Army. But, "which implementation method 
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is more efficient, centralized or decentralized in the Army 
environment?" and "what type of hardware should be installed 


morn cach level of unit’ are topics for future research. 
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APPENDIX A 


A BUSINESS MODEL 


A business model details how the organization operates 
and what is required to support the operations. The how 
and what aspects of an organization can be represented in 
terms of functions of the organization and the data classes 
Piatestpport these functions. 

A function in an organization is an essential activity 
or decision required to manage the resources and operations 
of the organization. Functions in an organization are 
identified by: 

(A) Examining statements of purpose of a task or an 
organizational area. 

(B) Examining work programs in an organizational area. 

(C) Identifying products or services provided by an 
organizational area and determining what functions are 
needed to produce such products or services. 

A data class in an organization is an aggregation of 
data (attributes) that is required by a function or is 
produced by it. Data classes are identified by examining 
the data required or produced by a function. 

Once the functions and data classes for each function 
have been identified, the definitions must be examined to 
assure they are consistent, non-redundant, and clear. A 


list of functions, data classes, and their definition, as 


TZ, 





well as a matrix showing which functions use which data 
classes, can then be specified. Such a matrix for depart- 
ments of ROK Army personnel management is shown on the 
fOllowing page, and the definition of each function is 


peevem im Chapter II. 
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APPENDIX B 


Meoavtebeeiebol OR INIEGRATED ENITITY*EYPES 


Different users in different functional areas usually 
require different data in each data class in the Business 
Model (Appendix A). Thus, common entity types must be 
extracted from the data classes through the integration of 
data in all functional areas for each data class. The 
description which follows names the entity types, defines 
what they represent, and lists their associated attributes. 

z. PERSON 
(rank, military serial number, name, social security 
number, order of son, main address, present address, 
COMMISSION (name of native military education course, the 
order of native military education course, DATE of COMMISSION 
(year, month, day), DATE of BIRTH (year, month, day), DATE 
of PROMOTION (year, month, day), BRANCH (original, special), 
FUNCTION (main, secondary), sex, type of blood, type of 
Pemroton, PUBLIC SERVICE (type of public service, maximum 
duration of total public service, final year of total public 
Service duration, maximum age for public service, final year 
of maximum public service age, maximum duration at a pointed 
rank, final year of maximum duration at a pointed rank). 
me PROMOEION LIST 
(military serial number, rank, DATE OF PROMOTION, 


(year, month, day), type of promotion). 





eee ee PARY CARRIER LIST 
eeeediny serial number, unit name, unit class, rank, 
@ety name, PERIOD (FROM (year, month, day), UNTIL (year, 
month, day), number of month)). 
mee MILITARY EDUCATION LIST 
(military serial number, rank, SCHOOL (name, course, 
order of course), PERIOD (FROM (year, month, day), UNTIL 
Wieat. month, day), mumber of month), average grade, order of 
average grade). 
See ALTH CONDITION LIST 
(mii tamvweserialenumber, rank, DATE OF CHECKING (year, 
momen, day), CONDITION (EYE (left, right class), EAR (left, 
meet, class), nose class, height, weight, TOOTH (up, down, 
Mees), HAND (left, right, class), FOOT (left, right, class), 
meena class, BLOOD PRESSURE (highest, lowest, class), lung 
class, neck class, round of chest), result of checking). 
oe © RIZE/ PUNISHMENT LIST 
iGamiks military serial number, kind of prize/ 
memashment, DATE (year, month, day), reason, point for 
epomotion). 
7. FOREIGN LANGUAGE CAPABILITY LIST 
(military serial number, kind of language, CAPABILITY 
(speaking, listening, reading, interpretation, translation)). 


8. CIVILIAN/ (NOT) FINISHED IN(OUT)-COUNTRY COMMITTED 
BOWE TTON LIST 


(lulwcaryssertal number, SCHOOL (country, name, 


address, major, academic degree), PERIOD (FROM (year, month, 


IES 





day), UNTIL (year, month, day), number of month), graduation 
Slassification). 
SNe PLANNED MILITARY EDUCATION 
(oCloOC he HalewscOUrse Order of course), branch, rank, 
number of person, required course, PERIOD (FROM (year, month, 
day), UNTIL (year, month, day), number of week)). 
10. ASSIGNMENT POLICY 
(unit class, rank, duty name, branch, function number, 
number of month for duration, required previous education 
for duty, required previous duty name for given duty). 
Sie homy, SECOND SERVICE ESTIMATION LIST 
(rantememil itary serial number, ESTIMATED DATE -(year, 
Momem, day), FIRST/SECOND ESTIMATOR (rank, name, duty 
Name), integrity, honesty, responsibility, personality, 
command capability, average grade, number of total estimatee, 
order of average grade). 
12. RECOMMENDED ORDER 
(rank, military serial number, RECOMMENDED DATE (year, 
month, day), RECOMMENDER (rank, name, duty name), number of 
total recomendee, recommended order). 
13. MINIMUM DURATION POLICY FOR RETIREMENT 
(name of native military education course, type of 
Meeli1c Service, number of month of the least duration for 


retirement). 
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APPEND IAC 


A LIST OF THIRD NORMAL FORMS 


The original entity types defined in Appendix B have 
Many anomalies which should be eliminated to realize an 
acceptable schema. Anomalies are caused by certain unwanted 
functional dependency structures. These anomalies can be 
avoided by forcing normal forms concepts and applying decompo- 
Sition stepwisely. As the result of this effort, a set of 
third normal forms are designed and described below. 
ieee PERSON 
(rank, military serial number, name, social security 
number, order of son, name of native military education 
course, the order of native military education course, 
main branch, secondary branch, main function, secondary 
mem@etion, birth year, birth month, birth day, type of blood, 
type of religion, type of public service). 
*PRIMARY KEY: military serial number 
2. COMMISSION 
(name of native military education course, the order 
of native military education Course, commissioned year, 
commissioned month, commissioned day). 
*PRIMARY KEY: name of native military education course 
+ the order of native military education course. 
moe 6 FUBLIG SERVICE LIMITATION POLICY 
(rank, maximum duration of total public service, maximum 
age for public service, maximum duration at a pointed rank). 


BERIMARY KEY: rank. 31 





Peo PERSON - 4 
(commissioned year, maXimum duration of total public 
service, final year of total public service duration). 
*PRIMARY KEY: commissioned year + maximum duration of 
total public service. 
*This subschema can be manipulated from (1-2) and (1-3) 
using a DBMS. 
feo PERSON =- 5 
(birth year, maximum age for public service, final 
year of maXimum public service age) 
*PRIMARY KEY: birth year + maximum age for public service. 
*This subschema can be manipulated from (1-1) and (1-5) 
using a DBMS. 
mo. PERSON - 6 
(promoted year, maximum duration at a pointed rank, 
final year of maximum duration at a pointed rank). 
*PRIMARY KEY: promoted year + maximum duration at a pointed 
Pane 
*This subschema can be manipulated from (1-3) and (2) using 
a DBMS. 
a PROMOTION LIST 
*Same as (2) in Appendix B, but combined attributes must be 
Comverted into simple attributes. 
*PRIMARY KEY: rank + military serial number. 
pee MIELITTARY CARRIER LIST 
*Same as (3) in Appendix B, but combined attributes must be 


Converted into simple attributes. 


82 





“PRIMARY KEY: military serial number + rank + duty name 
Wane OL Unit. 
fee tL TARY EDUCATION LIST 
*Same as (4) in Appendix B, but combined attributes must be 
converted into simple attributes. 
*PRIMARY KEY: military serial number + rank + school name + 
SOuUnsemlane teorcer Of Course. 
eee a eALTH CONDITION LIST 
*Same as (5) in Appendix B, but combined attributes must be 
converted into simple attributes. 
“PRIMARY KEY: military serial number + year. 
oe PRIZE/PUNISHMENT LIST 
(rank, military serial number, kind of prize/punishment, 
received year, received month, received day, reason). 
“PRIMARY KEY: military serial number + kind of prize + 
received year + received month. 
Sea, PRIZE POINT 
(kind of prize/punishment, point for promotion) 
@emiMARY KEY: kind of prize. 
7.  FOREING LANGUAGE CAPABILITY LIST 
*Same as (7) in Appendix B, but combined attributes must 
Memeonverted into simple attributes. 
*PRIMARY KEY: military serial number + kind of language. 


eee GIVILIAN/ (NOT) FINISHED IN (OUT)}-COUNTRY COMMITTED 
EDUCATION LIST 


(military serial number, school name, major, academic 


degree, from year, from month, from day, until year, until 
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[ioiedigeintil Gav, numper of month, graduation classification). 
*PRIMARY KEY: military serial number + school name + major 
+ academic degree. 
omcz. IN (OUT)-COUNTRY SCHOOL ADDRESS 
(school name, (country name,) school address) 
*PRIMARY KEY: school name. 
9.1. PLANNED MILITARY EDUCATION 
(school name, course name, order of course, number of 
mewsem, from year, from month, from day, until year, until 
month, until day) 
*PRIMARY KEY: school name + course name + order of course. 
mee. MILITARY EDUCATION POLICY 
(course name, rank, required course, number of week) 
*PRIMARY KEY: course name. 
ao. MILITARY EDUCATION COURSE 
(school name, course name, branch) 
*PRIMARY KEY: school name + course name. 
10. ASSIGNMENT POLICY 
*Same as (10) in Appendix B. 
*PRIMARY KEY: unit classification + rank + duty name. 
mie Pl koi SeeOND SERVICE ESTIMATION LIST 
*Same as (11) in Appendix B, but combined attributes must 
be converted into simple attributes. 


*PRIMARY KEY: military serial number + estimated year. 
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APPENDIX D 


A SAMPLE LIST OF RELATIONSHIPS 


A relationship corresponds to an aggregation of two or 
Mere entity types. For each entity type, a description of 
each relationship containing its name, entity types related, 
and mapping (one to one, one to many and many to many) is 
Peoduced., For example, PERSON HAS BEEN COMMISSIONED can 
be represented as an aggregation of the entity types PERSON 
and COMMISSION. A relationship is binary when only two 
entity types are aggregated, or of higher order (e.g., n- 


ary). However, most DBMSs handle only binary relationships. 


(e.g.) PERSON HAS BEEN COMMISSIONED (relationship) 

between PERSON and COMMISSION 
one to one (mapping) 

Pe FERSON HAS BEEN PROMOTED 
between PERSON and PROMOTION LIST 
one to many 

fe PERSON HAS CARRIED MILITARY CARRIER 
between PERSON and MILITARY CARRIER LIST 
one, CO Many 


DERSON HAS STUDIED MILITARY EDUCATION 


Gl 


between PERSON and MILITARY EDUCATION LIST 


one to many 
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APPENDIX E 
A SAMPLE DATA DICTIONARY 


A data dictionary is primarily a dictionary that defines 
the internally necessary attributes of the data for each 
database. The main functions of the data dictionary are 
as follows. 

1. The dictionary highlights ambiguity and inconsistency 


Metne data. Standard names, constraints, and sources are 


established. 
2. The dictionary provides documentation of all 
organizational data. It is a guide to what data is available, 


what it is called, where it is used, etc. 

3. The dictionary assists the DBA in maintaing configuration 
control over database. 

litte sdata dictionary should contain access authorities. 

These are contained in each database. To apply the above 
functions, the dictionary below contains 6 columns. These 
are: 

1. Field Name - This column indicates the standard field 
meme to represent attributes. 

Z. Explanation - This column explains the potential values 
for a given field. 

3. Type - This column represents a type of field value 
where "'n'' means numeric, "'an'' means alphanumeric and "a" 


means alphabetic. 
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octet “—aiteowcColunn represents the number of digits 
mor a potential field value. 

SS eeoimited Value = This field restricts the potential 
malues for a given field if the number of field values is 
limited. 

6. Remark - This column is free format, and includes keys 
and comments. 

However, the number of digits for field names as 
feevaples, types of fields, and length of field values are 


determined by DBMS capabilities and data characteristics. 
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APPENDIX F 


Aeon Mbie bio Or TRANSACTION PROCESSING ANALYSIS 


ihewamaty sis Of transaction processime Specifies inputs 

Bimc OUtputS, but does not involve the specific steps to obtain 
the output. This analysis is very helpful to end-user 
ieeliecdemean sSystemedesiuoners beGause at atfects the selection 
of levels and modules in the baseline hierarchical diagram 
of an application system. This analysis may result in a 
documentation as illustrated below. 

1. List or all officers' highest academic degree who are 


commissioned in a specific year for each source organization. 


a. functional areas : personnel policy department. 
DeeeioimawOusdeecess. | retrieval. 

c. entity types : commission, civilian education, person. 
d. relationships : person has been commissioned, person 


iaSesctuaied Gavarlian education. 
fem cGGeauency =< cach year. 


Mee soOcesSing pri@rity © I1I {priority could be divided 
Piromocewpes: Ll. 11 and II1). 


g. security : limited access. 
Mee Gepore formats. 


eeeesounce Oreanization §: XXXXXXXXxxxx 


(ey) se Be 








Be 


cae 


(2) MS : same format 


(3) MA : same format 


a) none (high school) : same format 


Source OL OFganezation : Same format. 


source of organization : same format. 


Lismeaon Minot mEcensmwho have periormed some Specific 


duty and received military education to select some officers 


for new assignments. 


a. 


De 


functional areas : assignment department. 
Kinet aecess ¢ reenleval. 


Tema me Mcmsoom., NilLitary Carrier, ist , 
military education list. 


relationship types : person has military carrier, 
person has studied military education. 


frequency : every day. 
Seeess Prioritygs i. 
security : free. 


neport LOrmat. 





iia t. XXXXXXXX 


om 





6; 


iO .. 


iil. 
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